AD-A265  878 

■iiniiii 


University  of  Southern  California 
Information  Sciences  Institut^EARED 
Common  Lisp  Framework* 

Final  Technical  Report  ^  ®  4 


David  S.  Wile 


DRECTORATEFOR 

ANO  SECUfUTY  REVtW 
department  Of  OtFCNSE 


Sponsored  by  Defense  Advanced  Projects  Agency  (DOD|  ^  ^ 

DARPA/CSTO 
Title  of  Contract: 


“A  Proposed  Research  Program  in  Strategic  Computing” 
Project:  Common  LISP  Framework 
DARPA  Order  No.  6096 


Issued  by  DSS-W  under  Contract  MDA903-87-C-0641 
Period  of  Performance:  09/01/87  -  05/31/92 


February  8,  1993 


m 


•m 


J  O 


.  I 

Hi  134 19 


’The  views  and  conclusions  contained  in  this  document  must  not  bf  interpreted  as  rep¬ 
resenting  the  official  policies  either  expressed  or  implied  of  the  Defense  Advanced  Research 
Projects  Agency  or  the  U.S.  Government. 


■a.  MtlKWr  MRCgMTV  CtASWFICATKIN 


REPORT  DOCUMENTATION  PAGE 

I  'a.  rcstrictivc  MAMONoa 


aa.  stcuarry  ccMaMCATioN  authomitv 


a.  OtSTRWJTION/AVAlLAM.Ty  Of  HOKMT 


4.  awowMaao  omoamzation  maont  nummnc*) 


I  a.  MOMTonaM  onoANUATioN  mcaoat  Nuaaacaiai 


aa.  NMM  Of  msmfomtmta  OAOAMXAnoN 

use 

INF<^mATION  SaSNCES  INSTITUTE 

ia.  AMMCn  iCUy,  tUla.  ana  ZIP  Caaal 

4678  Admiralty  Way 

Marina  dal  Ray.  California  90262 


aa.  omec  aviaaot. 


I  Ta.  NfJM  Of  MOMTOMNO  OACAMZATION 


I  7k.  AODRESa  (Olr.  Sialt.  ana  Z«  Coot) 


aa.  NOAM  or  wj»»NO/apONaoaa40 
onaarazAnoN 

Offiaa  ef  Kavai'Rtiieareh 


ak.  omca  aYiMOk 


a.  MtocLMaMaMT  axamuiyiaMr  ecMmcATioN  i 


MDA903-87-C-0641 


raooAAM 
lUMaMT  NO. 


mojccT  NO. 


JWOHK  UMT 

ACcaaaiON  no. 


II.  Tma  ikicmoa  aacumrv  ctAaawcA-noN) 

Common  Lisp  Framewoiic 


a.  rfRaoNAL  AUTHontai 

David  S.  Wile 

iia.  rrra  or  napoar 

Final 

w.  awppuMDaTAMv  notation 


Ilk.  TBaacovfNto 


M.  OATI  or  IPOAT  (Vaar,  MunUADayl 

February  8, 1993 


IS.  PAAI  COUNT 


coaATi  cooaa 


The  prindplelgoal  of  the  COMMON  LISP  Framework  project  was  to  support  Strategic  Computing  (SC) 
contractorsJWuh  a  comprehensive,  state-of-the-art  programming  framework  for  the  development  and 

evolution  of  COMMON  LISP  programs.  The  CLF  has  affected  the  technical  community  by  shaping  both 
the  structure  of  modem  programming  environments  and  the  development  paradigm  they  support.  This 
structure  rests  upon  an  active  objeetbase  which  maintains  integrity,  integrated  tools  and  provides  persistence. 
CLF’s  integrity  management  is  unique  in  providing  declarative  integrity  condition  statements-which  can  be 
reasoned  about  and  analyzed— while  still  permitting  efficient  algorithmic  maintenance  of  these  conditions. 

Its  declarative  persistence  mechanism,  based  on  conceptual  aggregations  of  objects,  is  also  unique.  Tools  are 
integrated  with  the  objeetbase  rather  than  each  other.  They  gather  their  inputs  from,  and  place  their  results 
back  in,  the  objeetbase  and  are  invoked  (demonically)  by  relative  activity  in  the  objeetbase. 

The  final  years  of  the  COMMON  LISP  framework  project  were  primarily  devoted  to  extracting  important 
functionality  from  the  CLF  and  packaging  it  in  a  form  suitable  for  use  in  other  environments.  This  allowed 
its  use  by  clients  who  could  not  use  the  monolithic  CLF  system  in  their  in  place  system  architectures. _ 
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Task  Objectives 


The  principal  goal  of  the  COMMON  LISP  Framework  project  was  to  support  Strate¬ 
gic  Computing  (SC)  contractors  with  a  comprehensive,  state-of-the-art  programming 
framework  for  the  development  and  evolution  of  COMMON  LISP  programs.  This 
framework  provides  the  programmer  with  a  fileless  environment  of  persistent  objects. 
Their  relationships  with  other  objects  are  manipulated  via  a  set  of  generic  operations 
and  are  used  to  associatively  retrieve  the  objects.  The  COMMON  LISP  Framework 
system  (the  CLF)  maintains  the  consistency  of  these  objects  and  initiates  automated 
processing  for  the  programmer  via  a  set  of  rules. 

The  CLF  has  affected  the  technical  community  by  shaping  both  the  structure 
of  modern  programming  environments  and  the  development  paradigm  they  sup 
port.  This  structure  rests  upon  an  active  objectbase  which  maintains  integrity,  inte 
grates  tools,  and  provides  persistence.  CLF’s  integrity  management  is  unique  in  pro¬ 
viding  deciar<itive  integrity  condition  statements-which  can  be  reasoned  about  and 
analyzed-while  still  permitting  efficient  algorithmic  maintenance  of  those  conditions. 
Its  declarative  persistence  mechanism,  based  on  conceptual  aggregations  of  objects,  is 
also  unique.  The  persistence  of  these  aggregates  is  automatically  maintained.  Tools 
are  integrated  with  the  objectbase  rather  than  each  other.  They  gather  their  inputs 
from,  and  place  their  results  back  in,  the  objectbase  and  are  invoked  (demonically) 
by  relevant  activity  in  the  objectbase.  Military  and  societal  impact  will  accrue  from 
the  infusion  into  routine  practice  of  programming  environments  which  maintain  all 
information  relevant  to  the  programming  process  within  them;  viz.,  product  lifetime 
support,  synergistic  tool  support  and  tightly  coupled  systems. 

The  final  years  of  the  COMMON  LISP  Framework  project  -  covered  in  this  report 
-  were  primarily  devoted  to  two  goals,  one  mundane  and  the  other,  laudable.  First, 
we  needed  to  port  the  CLF  to  our  Hewlett  Packard  400  Series  workstations  as  the  un¬ 
derpinnings  for  our  everyday  computing  environment.  More  importantly,  we  wanted 
to  open  up  our  technology  to  other  researchers  by  extracting  important  functionality 
from  the  CLF  and  packaging  it  in  a  form  suitable  for  use  in  other  environments. 
This  allowed  use  of  the  functionality  without  potential  clients  having  to  buy  off  on 
the  monolithic  CLF  system,  which  often  could  not  be  used  in  their  in-place  system 
architectures. 


Technical  Problem 


□ 


The  idea  for  the  COMMOjN  LISP  Framework  project  arose  as  D.'XRl’A  recognized  the  n _ _ 

importance  of  the  ongoing  research  in  the  Formalized  System  Development  project — - - 

at  ISI,  especially  its  potential  for  use  bv  its  SC  contractors.  The  project  began  in - - 
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Figure  1:  FSD-CLF  plateau  cycle 

1984.  A  prelimin2Lry  version  of  the  CLF  was  in  beta  test  by  the  end  of  1986  and  was 
delivered  to  other  SC  contractors  in  early  1986. 

Hence,  CLF  was  basically  a  technology  transfer  project,  adapting  well- understood 
aspects  of  the  FSD  system  to  COMMON  LISP  programming  support.  The  develop¬ 
ment  cycle  of  functionality  obeyed  the  diagram  in  Figure  1.  As  each  system  feature 
matured  in  the  FSD  system,  it  was  incorporated  into  the  CLF.  That  CLF  facility  then 
became  the  foundation  for  the  next  version  of  the  FSD  system.  Generally,  features 
underwent  two  distinct  phases.  The  initial  “demonstration”  phase  (FSD  DemOn)  was 
incomplete  with  respect  to  some  intended  functionality,  but  demonstrated  a  portion 
of  that  intended  functionality  as  a  straw'  man,  a  rapid  prototype.  After  about  three 
months,  the  demonstrated  features  were  robust  enough  to  endure  “alpha  test*  in  ISl 
applications.  They  then  became  official  FSD  .system  features  (FSD  System^)  and 
were  “beta  tested”  at  ISI  for  several  months  by  a  w'ider  user  community  before  being 
incorporated  into  the  CLF  (CLF  Plateau„).  This  plateau  then  became  the  base  of 
the  next  FSD  demonstration. 

From  the  outset,  the  COMMON  LISP  Framework  was  int<‘nd('(i  to  go  througii 
three  major  phases.  The  functionality  of  the  initial  CLF  was  bc'st  charactenzed  as 
flexible  management  of  program  objects  and  to<ds  A  pr<’limiriary  version  of  this 


portion  was  in  beta  test  at  the  end  of  1985  and  was  delivered  to  other  S(,'  contractors 
in  early  1986.  During  the  second  phase,  the  tools  provided  in  the  initial  sysleni 
were  made  more  reliable  and  robust.  The  third  phase  was  to  begin  to  incorporate 
the  FSD  technology  for  program  specification,  implementation  via  transformation, 
and  reimplementation  via  replay  of  previously  formalized  developments  on  changed 
specifications.  These  phases  were  viewed  as  merely  the  first  of  many  in  which  spinoffs 
from  the  FSD  testbed  are  incorporated  into  the  CLF'  for  technology  transfer  to  the 
SC  contractors. 

The  functionality  of  the  initial  CLF  was  best  characterized  as  fully  flexible  man 
agement  of  all  program  objects  and  tools.  It  incorporated;  the  relational  database 
of  program  objects  (modules,  functions,  record  declarations,  etc.),  analysis  predi 
cates  (flow  relationships,  call  relationships,  variable  usag<‘  patt<’rns)  via  which  ail 
tools  communicate;  facilities  for  creation,  modification,  dc'st ruction,  retention,  orga 
nization,  and  retrieval  of  these  objects;  the  interactive  standardized  u.ser  interface  to 
these  facilities  using  a  menu/window  system;  tools  which  interface  to  these  objects 
including  the  ZMACS  editor  and  a  batch  invoked  tool  for  program-  and  data-flow 
analysis;  and,  the  “DEVELOP”  mechanism  to  record  a  history  of  change  within  the 
FSD  environment. 

The  system  was  released  for  “beta  test”  in  FY86,  incorporating:  a  facility  for 
converting  existing  programs  for  use  in  the  framework;  a  preliminary  facility  for 
managing  system  releases  based  on  the  DEVELOP  facility  mentioned  above;  and, 
a  brief  manual  and  an  excellent  on-line  tutorial  introduction  to  normal  u.sage  of  the 
system.  Access  to  the  underlying  CLF  facilities  was  provided  so  that  developers  could 
provide  a  “consistent  underlying  viewpoint”  to  the  users  of  their  facilities.  CLF  was 
ported  into  Common  Lisp  and  onto  other  host  machines. 

During  the  second  phase,  the  tools  provided  in  the  initial  system  were  made  more 
reliable  and  robust;  new  versions  of  the  database  and  our  interface  were  incorporated 
to  increase  responsiveness  through  heterogeneous  data  representation  and  to  provide 
object-oriented  browsing  and  editing. 

In  fact,  the  technical  problem  was  redefined  during  the  progress  of  the  current 
contract,  for  two  fundamental  reasons: 

•  The  FSD  technology  for  program  spf-cifiratiori,  Iran.sformat i<Hi,  and  develup 
ment  replay  did  not  progress  rapidly  enough  to  advantageously  be  incorpo¬ 
rated  in  the  CLF.  Indeed,  the  technology  ultimately  was  rejected  in  favor  of 
a  more  domain -specific  aproach  to  specifiralion  and  a  much  more  automated 
way  of  developing  goo<i  imi)lemen'af io>’s  (See  follow  oTt  ]>roject.  “.tunofufm??- 
4  Metaprograms"'. 

•  1  he  CLF  was  not  acrei)te<i  externally  because  it  was  perceived  as  a  “inonoliih" 
which  had  to  be  accepte<l  a.s  a  whole,  rather  than  ado[)te<i  iie  renient ally  into 


existing  environments  containing  important,  entrenched  functionality. 

ifence,  the  technical  problems  gradually  devolved  to  exporting  the  lechiioiog>  in 
a  form  suitable  for  use  by  other  technologists.  This  involved  porting  the  CLF  to  an 
open-architecture  system,  Unix,  before  we  could  sc.iously  propose  that  others  use 
the  system  components  (they  were  written  for  Lisp  Machines  of  the  early  19S0sj. 
Of  course,  then  there  w’as  considerable  refining,  redesigning  of  component  interfaces, 
production  of  user  manuals,  etc.,  so  they  could  indeed  by  extracted  from  lh<.  .systi  ni 
and  presented  to  e  eternal  users. 

3  General  Methodology 

3.1  Salient  Features  of  the  CLF 

The  COMMON  LISP  Framework  comprises  the  following  major  components: 

•  AI  Operating  System  (CLF  Kernel); 

•  Program  Management  Service; 

•  Program  Development  Service. 

The  A I  operating  system  kernel  of  the  CLF  provides  the  programmer  with  a  fileless 
environment  of  persistent  objects.  Their  relationships  with  other  objects  are  manipu¬ 
lated  via  a  set  of  generic  operations  and  are  used  to  retrieve  the  objects  associativelv. 
The  CLF  maintains  the  consistency  of  these  objects  and  initiates  automated  process¬ 
ing  for  the  programmer  via  a  set  of  rules. 

A  unique  feature  of  the  CLF  is  that  all  objects  manipulated  by  programmers  are 
represented  in  this  persistent  object-b<ise  —  specifically  structured  objects,  like  mod¬ 
ules  with  components,  as  well  as  primitive  program  structures,  like  function,  variable, 
and  structure  declarations.  Also,  relationships  and  objects  elsewhere  represented  in 
a  very  ad  hoc,  diversified  fashion,  such  as  flow  analysis  relationships,  versions,  time 
stamps,  developers,  and  u.sers,  are  all  represented  uniformly  in  the  ol)jecl-t>;Lse. 

The  kernel  provides  generic  facilities  for  maniiiulatlng  thesi-  programming  object.-; 
as  objects.  In  addition,  special  facilities  have  been  introduced  info  the  framework  to 
provide  programming  assistance  in  the  following  areas: 

•  Module  creation; 

•  Component  adiiition; 


•  Component  modification  and  editing; 

•  Code  instaliation. 

Each  of  these  facilities  requires  user  intervention  or  initiation. 

Especially  important  are  the  facilities  for  managing  the  consistency  of  program 
information,  built  using  the  rule-based  kernel.  These  facilities  perform  the  following 
activities; 

•  Automatically  compile  functions  that  are  “installed”  by  the  user; 

•  Allow  multiple-buffer  editing  of  the  same  object  while  maintaining  correct  views 
in  each  buffer; 

•  Automatically  (re)analyze  functions  when  they  are  installed: 

•  Automatically  maintain  program  object  ordering  by  load-order  and  view-order. 

Each  of  these  activities  is  managed  differently  in  existing  programming  environments. 
Some  are  managed  by  the  user  only-the  system  provides  no  help  for  such  consistency 
maintenance. 

The  CLF’s  Program  Development  Service  provides  automated  maintenance  docu¬ 
mentation  by  maintaining  an  annotated  development  history.  The  user  is  responsible 
for  providing  development  step  annotations  briefly  characterizing  his  activity  when 
he  changes  the  program.  The  programmer  may  explicitly  indicate  substructure  in  his 
development,  whereupon  the  system  maintains  his  stated  goal  structure. 

Of  considerable  importance  is  the  ability  of  a  user  to  indicate  his  plans  for  future 
programming  activity,  through  creation  of  development  steps  called  “pending  steps.” 
The  user  can  subsequently-perhaps  at  a  much  later  time-handle  these  development 
steps;  the  system  automatically  incorporates  them  as  new  steps  in  the  existing  struc¬ 
tured  history. 

Not  only  is  the  development  service  able  to  recall  the  history  of  the  programming 
activity  itself,  but  it  is  linked  into  the  persistent  object-base  management  activity  in 
such  a  way  that  information  associated  with  the  changes  may  be  used  for  maintenance 
documentation  and  release  and  for  version  management.  Thus,  since  the  generic 
object-base  facility  is  used  to  store  the  development  history  itself,  one  can  find  ail  the 
development  steps  affecting  a  particular  object,  as  well  as  all  the  objects  affected  by 
a  particular  development  step. 

1  his  link  into  the  incremental  saving  mechanism  allows  the  development  service 
to  provide  automated  dislri!)ution  of  program  objects  to  users  of  the  systfuns  of  \vhi(  h 
they  are  components,  as  well  a.s  to  ai<l  in  tracking  the  installation  of  sets  of  changed 
program  objects  when  the  affecting  development  steps  are  acct'pteii.  I’he  docutnenta- 
tion  used  tf)  describe  development  steps  is  uovl  to  do<'ument  tin-  <list  ribntt'd  changes 


to  users  of  the  system.  This  is  a  particularly  interesting  side-effect  of  our  efforts  to 
record  as  much  as  possible  of  the  programming  process  in  the  machine,  where  the 
information  can  be  analyzed  and  the  user  aided  based  on  this  analysis. 

The  reader  may  feel  more  comfortable  with  these  concepts  by  considering  the 
normal  usage  scenario  in  Figure  2.  New  users  of  the  CLF  usually  have  running 
code  that  they  must  import  into  the  CLF  environment.  Often  they  will  analyze 
and  reorganize  their  original  flat  files  into  a  more  logical  structure  of  nested  modules 
using  the  CLP^’s  object  manipulation  capabilities.  After  this  importing  is  complete, 
the  development  phase  is  repeatedly  performed.  In  each  cycle  development  steps 
are  created,  augmenting  the  system,  fixing  a  bug,  or  tuning  the  .system.  A  series 
of  modifications  is  made  to  accomplish  that  change.  The  changes  are  installed  and 
tested.  When  the  changes  work  properly,  the  development  stej)  is  closed  and  the 
changes  in  it  are  distributed  to  the  user  of  the  modified  system.  All  of  this  reror<ling. 
installation,  and  distribution  is  automated. 

From  time  to  time  the  developer  needs  to  reestablish  his  persistent  objcct-ba.se 
in  a  new  virtual  address  space  (e.g.,  when  a  new  version  of  the  CLF  is  released  or 
when  the  system  crashes).  The  distribution  information  automatically  saved  by  the 
CLF  is  sufficient  to  automatically  restore  the  current  state  of  his  systems  and  their 
development  in  the  new  object-base. 

3.2  Conversion  and  Porting 

The  general  approach  taken  in  converting  facilities  in  the  existing  CLF  in  order  to 
port  them  onto  a  Unix  platform  was  to  convert  base  functionality,  o-test  it  for  a 
few  weeks  on  the  new  platform,  and  then  let  the  rest  of  the  Software  Sciences  Divi¬ 
sion  personnel  P-tesi  it  to  wring  out  the  bugs.  This  entailed  converting  the  “APS” 
system  —  our  virtual  memory  database  programming  language  —  before  any  of  the 
rest.  A  second  major  problem  involved  the  linkage  between  the  editor,  Epoch,  and 
the  Common  Lisp  system.  On  the  Lisp  machine  implementations  of  the  CLF  from 
previous  years,  the  editor  was  an  implicit,  integral  part  of  the  Lisp  environment.  On 
the  Unix  platform,  the  editor  process  was  quite  .separate  from  Lisp,  and  did  not  corn 
municate  with  other  processe.s.  Hence,  another  major  conversion  problem  was  setting 
up  a  remote  procedure  call  linkage  betwc'en  the  Common  Lisp  process  and  th<  ■  ditor 
proce.ss,  through  the  use  of  Unix  “sockets."  Some  details  of  the  porting  process  are 
reported  in  the  Technical  Results  section  below. 

3.3  Exporting  Components 

The  approach  to  component  exportation  wa.s  quite  simple;  we  identified  wliicfi  com 
porient.s  could  be  expf)rlefi,  what  other  component.'-  they  relii'fl  on  both  internally 


Startup  Phase: 
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Save  module 

Update  systems  in  new  band 


Figure  2:  Normal  Usage  Seen 


produced  and  externally  produced,  and  then  made  them  available  a.s  they  were  ported 
This  last  task  sometimes  entailed  decoupling  them  from  their  environment  and  tisn 
ally  required  producing  some  kind  of  user  manual  or  at  least  a  reference  manual  for 
them. 

The  components  we  identified  early  as  both  suitable  and  desirable  for  exportation 
are  described  in  Figure  3.  Several  other  components  arose  during  the  course  of  the 
project  which  were  also  made  available  for  distribution.  These  ar«>  all  described  belf)vv 
in  the  Technical  Results  section. 


4  Technical  Results 

4.1  APS 

.'\P.5  is  the  basis  for  the  AI  operating  .system  f)rovided  by  the  CIJ'.  In  particular, 
it  is  an  extension  of  Common  Lisp  providing  a  virtual  memory  data  base  with  au 
tomatic  consistency  maintenance,  demonic  function  invocation,  and  user-suppliable 
implementations  for  relations. 

During  F'YS?,  we  introduced  several  “specification-based”  facilities  to  separate 
specification  of  functionality  from  implementation.  Foremost  was  compiler  “annota¬ 
tions”  which  instruct  the  compiler  to  choo.se  particular  representations  for  abstract 
data  structures,  and  to  optimize  based  on  size  and  effort  estimates  for  particular 
structures.  Another  such  annotation  was  to  allow  POPART’s  ability  to  build  and 
maintain  grammatical  structures  act  as  relations.  \Vc  al.so  incorporated  incremental 
flow  analysis  and  compilation  facilities. 

Basically,  AP5  was  ready  for  exportation  as  soon  as  it  was  ported  to  the  Unix 
based  Common  Lisp  system.  An  important  training  manual  was  written  to  enhance 
its  appeal. 

4.2  Worlds 

“W'orlds”  was  a  less  mature  systen  ,  built  on  top  of  AP-b  to  provide  persisten(<’  for 
virtual  database  objects  and  relations.  Worlds  partition  the  dataha.se  into  layers  of 
coiic<‘ptually  relat«‘d  data  which  can  b«-  conipose<]  to  construct  “complete'  objf'ct.s 
or  relations.  The  mechanism  is  now  used  routinely  to  maintain  mail  and  personnel 
data  and  is  in  experimental  use  in  maintaining  programming  service  data.  Worlds  is 
unique  in  tliat  a  world  i.s  really  just  a  “view"  of  the  fiatalia.se  rar<'ly  including  all 
attriliutes  of  any  particular  object  that  it  contains. 

During  FY88  the  worlds  system  matured  consid«'rably.  During  l'A’89  we  intro 
diiced  a  facility  we  built  to  allow  users  to  sp<Tify  a  set  of  ‘seeds’  via  a  })re(licate.  The 


The  CLF  Framework  itself: 

Dependencies:  Common  Lisp,  one  of  Symbolics  3600,  TI  Explorer, 

HP  Bobcat 

Interface:  Extends  envirotunent  of  host  machine 
Description:  (See  text) 

APS 

Dependencies:  Common  Lisp 

Interface:  Language  extension  to  Common  Lisp 

Description:  Provides  virtual  memory  data  base  vith  automatic 

consistency  maintenance,  demonic  function  invocatu: 
and  user-suppliable  implementations  for  relations. 


Forms  Kit 

Dependencies:  Com- on  Lisp,  X-Windows,  Common  Objects 
Interface:  Common  Lisp  macros  for  form  definition;  function 
invocation  for  display. 

Description:  Generic  object  display  mechanism  with  support  for  a 
variety  of  standard  formats. 


Popart 

Dependencies:  Common  Lisp 

Interface:  Function  calls,  ZMACS  macros,  pseudo-LISPX  macros  » 

Description:  Language  independent  programming  environment 

generator  from  lai^guage  description  in  BNF  variant. 

Provides:  parser,  pattern  matcher,  lexical  analyzer, 
pretty-printer,  semantic  "action"  routine  mecheunism, 
structure  editor,  emd  transformation  system.  ' 


Worlds 

Dependencies  ;  AP5 ,  Cortinon  Lisp 
Interface:  Function  invocation 

Description:  Object  persistence  maintenance  mechanism  based  on 
conceptual  aggregates  of  types  and  relations  into 
"worlds" . 


Popart-DB 

Dependencies;  APS,  Popart,  Common  Lisp 
Interface:  Popart  and  APS  Interfaces 

Description:  Integiutes  Popart’s  abstract  syntax  declarations  for 
a  grammar  with  APS 's^  relation  and  type  declarations. 
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worlds  mechanism  then  uses  this  predicate  to  start  its  closure  algorithm  to  determine 
what  belongs  in  the  world.  Most  importantly,  the  mechanism  understands  the  in- 
cremenlal  changes  to  the  seed  set  when  subsequently  invoked  to  repopulare  a  world 
that  has  changed.  This  somewhat  simple  enhancement  will  significantly  decreased 
the  overhead  of  the  users  of  the  persistence  mechanism.  We  al-'o  discovered  thai 
the  simultaneous  commital  of  information  from  several  worlds  to  the  persistent  store 
can  be  done  more  efficiently  than  the  sequential  commital  of  each.  We  modified  the 
algorithm  to  take  cidvantage  of  this  opportunity. 

use  graduate  student  Surjatini  Widjojo  completed  a  demonstration  system  (for 
her  dissertation  work)  called  “Worldbase”.  This  system  allows  the  definition  of  worlds, 
information  aggregates  which  can  be  used  to  make  persistent,  data  accumulated  in 
the  workstation,  The,se  world  images  can  then  ix*  loadeij,  transformed,  and  merged 
into  other  workstation  environments.  This  is  esp<'cialiy  nice  work  giving  the  project 
visibility  in  the  database  community. 

4.3  Popart 

Popart  is  a  language  independent  programming  environment  generator  that  takes  a 
language  description  in  BNF  variant  and  provides  a  parser,  pattern  matcher,  lexica! 
analyzer,  pretty-printer,  semantic  "action”  routine  mechanism,  structure  editor,  and 
tr  msformation  system.  It  was  developed  under  DARPA  and  NSF  support  during 
the  late  1970s  and  early  1980s.  It  is  unique  in  that  it  provides  a  concrete  syntactic 
view  to  all  tool  builders  and  users  of  the  system,  aespite  maitaining  everything  in  an 
abstract  syntax  internally.  This  is  just  one  aspect  that  makes  it  extremely  useful  for 
rapid  prototyping  of  language  processing  facilities. 

Early  in  1989,  the  FSD  project  developed  “Barrel”,  a  ‘Passive  Virtual  Database’ 
programming  architecture.  It  shares  AP5’s  representation  library  concept  with  the 
active  database  architecture  but  requires  no  run-time  support,  and  thus,  no  run-time 
overhead.  This  invention  presented  an  opportunity  to  generalize  our  Popart  .system 
considerably.  Particular  areas  of  generalization  were: 

•  Grammar-related  state  variables.  Previously,  most  grammar  related  inform. i 
tion  was  only  accessible  in  one  direction,  viz  from  the  grammar  to  the  infor 
mation.  There  are  situations  where  it  would  be  useful  to  access  the  grammar 
from  the  information.  This  was  simply  impossible  without  ro.isiderahle  rejiro 
gramming.  Representing  these  relationships  as  Barrel  relations  gives  us  the 
flexibility  of  changing  the  representation  and  allowing  the  inverse  ai  <  ee-  with 
out  changing  the  program  at  all.  More  important,  over-rest riclivf’  <  .(ii.si  rain:  > 
on  uniqueness  of  names,  productions,  operators,  etc.,  were  required  in  the  pa.st. 
because  these  bits  of  information  were  not  [parameterized  with  respe<  t  to  the 


grammar  in  which  they  occur.  This  quarter  we  reparameterized  these  items, 
allowing  the  relaxation  of  the  uniqueness  constraints. 

•  Similarly,  the  abstract  syntax  used  in  Popart  was  very  rigidly  implemented 
using  list  structures.  Barrel  allowed  us  first  to  generalize  the  abstract  syntax  to 
include  the  grammar  of  which  it  is  a  part  as  an  argument  to  relations  describing 
it.  Then  differential  abstract  syntaxes  (for  different  grammars)  were  invented. 

The  reprogramming  of  Pc^»art  to  incorporate  these  two  extensions  was  a  major  ac¬ 
complishment  of  FY90.  About  85%  of  the  code  that  we  intended  to  convert  was 
converted  and  tested.  This  not  only  effected  a  cleaner,  easier- to- modify  version  of 
Popart  but  allowed  for  additional  functional  enhancements’. 

During  FY91,  a  generic  facility  to  permit  “whitespace  parsing”  was  added  to  the 
Barrel  version  of  Popart.  The  unique  feature  of  this  mechanism  is  its  unobtrusive 
impact  to  the  original  syntax  of  the  language  in  which  the  whitespace  is  embedded. 

4.4  Luke 

An  important  component  developed  in  the  FSD  project  and  subsequently  exported 
through  the  CLF  project  was  LUKE  (Lisp  Universal  Kode  Elaborator),  a  code  walking 
“shell”  for  C!ommon  Lisp  and  languages  embedded  within  it.  Code  walkers  are  used 
for  a  variety  of  program  analysis  tools.  Luke  is  a  shell  in  the  sense  that  it  p>crforms  no 
useful  task  in  its  own  right;  it  must  be  tailored  to  a  particular  application  by  providing 
certain  methods  that  determine  the  code  walking  path  and  result  computation  for  that 
application.  LUKE  can  be  used  either  to  compute  a  transformation  (some  image)  of 
a  piece  of  code,  or  solely  for  side  effect  —  e.g.,  to  gather  statistics  about  the  code. 

Conceptually  LUKE  derives  extensibility  by  viewing  the  task  of  code  walking  as 
an  example  of  recursive  descent  programming,  and  enabling  the  programmer  to  fau:tor 
concerns  about  a  ^ven  recursive  descent  application  into 

•  the  problem  of  identifying  the  relevant  subtrees  of  a  given  tree,  and 

•  the  problem  of  composing  the  result  for  a  given  application. 

Programmatically  LUKE  derives  extensibility  from  its  implementation  in  CLOS. 
This  enables  the  user  to  define  a  new  application  as  a  specialization  of  another,  similar 
application  and  to  describe  only  the  differences.  The  use  of  mulitmethods  enables 
these  differences  to  be  described  in  terms  of  a  “natural”  syntax  for  Common  Lisp. 

‘Although  moot  of  the  reprogramming  of  Popart  was  concluded,  the  efficiency  with  which  it 
runs  was  never  acceptable:  the  appropriate  Barrel  annotations  were  not  programmed.  Hence,  the 
reprogrammed  Popart  did  not  replace  the  existing  one  for  most  of  its  u.ser  community.  As  time 
permits,  follow-on  contracts  will  continue  development  of  the  Barrel  version  of  Popart. 
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The  standard  LUKE  shell  maintains  contextual  information  that  can  be  accessed 
by  an  application,  including:  declarations  in  effect  for  the  code  being  processed,  en¬ 
closing  lexical  blocks,  eticlosing  named  definitions,  and  contextually  imposed  type 
requirements.  LUKE  provides  a  Umplate  language  to  ease  the  programming  of  ex¬ 
tensions  to  cover  user-defined  macros.  Templates  are  compiled  into  methods,  not 
interpreted  during  the  code  walk. 

4.5  APS,  Barrel,  and  Compilation  Framework 

As  was  mentioned  above,  early  in  1989,  the  FSD  project  developed  “Barrel”,  a  ‘Pas¬ 
sive  Virtual  Database’  programming  architecture.  It  shares  AP5’s  representation 
library  concept  with  the  active  database  architecture  but  requires  no  run-time  sup¬ 
port,  and  thus,  no  run-time  overhead.  In  the  CLF  project,  Barrel  was  extended  to 
keep  track  of  statistics  of  relation  update  and  access  for  those  relations  using  the 
default  implementation.  After  using  a  system  for  a  while,  the  user  can  then  check  to 
see  what  relations’  speeds  are  proving  to  be  bothersome. 

At  the  same  time,  a  Relational  Abstraction  Compilation  Framework  was  develoi>ed 
in  the  FSD  project  which  generalizes  both  the  Barrel  compiler  and  the  APS  compiler 
to  provide  a  framework  for  compiling  extensions  to  arbitrary  prc^amming  languages 
to  provide  relational  abstraction.  Some  of  that  work  was  taken  up  by  the  CLF  project 
as  the  FSD  project  wound  down.  In  particular,  methods  were  added  to  allow  more 
update  interfaces  to  the  abstract  relations.  A  more  elegant  encapsulation  of  retrieval 
methods  was  also  discovered,  whereby  despite  using  surj  iterative  interface  to  retrieval 
generation,  efficient  single-selections  and  simple  queries  are  supported. 

During  FY9I  the  framework  was  extended  in  two  major  ways: 

•  Derived  relations  in  logic  formulae  were  implemented.  Target-language-independent 
algorithms  are  produced  (consisting  of  neutral  instructions  like  “generate  this 
domain  first”,  “test  this  predicate  now”,  etc.)  by  the  well-formed-formula  com¬ 
piler.  Subsequently,  target-language-specific  source  code  generators  and  cost 
estimators  are  invoked  by  the  framework. 

•  A  compositional  specification  language  was  designed  and  implemented,  allowing 
users  to  describe  how  to  represent  a  relation  by  composing  different  indexing 
regimes  from  a  library  of  predefined  representations. 

4.6  Forms  Kit 

“1  Tms  Kit”  is  a  generic  object  display  mechanism  with  support  for  a  variety  of  stan¬ 
dard  layout  formats.  It  was  another  component  whose  functionality  was  obviously 


ready  for  exportation,  but  whose  porting  onto  Unix  platforms  was  problematical  be¬ 
cause  of  the  discrepancies  between  X-windows  and  the  idiosyncratic  window  systems 
of  the  Lisp  Machines.  In  addition,  it  made  several  assumptions  about  the  existence 
of  APS,  which  made  it  inappropriate  for  exportation  to  the  research  community  — 
there  was  no  reason  for  us  to  bundle  these  two  potential  products  together^. 

During  FY88  we  completed  the  design,  implementation,  and  documentation  of  a 
specification-based  user  interface,  independent  of  APS.  Sf>ecifications  control  content, 
layout,  graphic  characteristics,  and  user  interaction  with  displayed  data.  We  also 
particularized  this  tool  (by  adding  a  new  abstr2u:t  interface)  for  use  within  CLF  so 
that  the  data  is  obtained  from  the  APS  database  and  the  form  is  kept  consistent  with 
changes  in  the  database. 

During  FY89  the  Forms  Kit  was  enhanced  in  the  following  ways: 

•  The  performance  of  our  Screen  Updater,  which  keeps  views  up-to-date  with  the 
objectbase,  was  improved  with  the  implementation  of  a  new  algorithm  based 
on  the  observation  that  the  number  of  distinct  relations  modified  in  a  typical 
objectbase  update  is  quite  small,  whereas  the  number  of  interface  units  whose 
contents  are  sensitive  to  the  objectbase  may  be  large. 

•  We  improved  the  update  speed  for  small  form  changes  by  BITBLTing  informa¬ 
tion  that  has  not  changed  into  new  locations,  rather  than  recomputing  it  as  is 
our  current  praw:tice. 

•  The  Forms  Kit  system  was  factored  into  the  subset  necessary  to  create  and 
present  forms  ai»d  the,  subset  controlling  user  interactions,  so  that  now  the 
system  builders  can  use  the  underlying  CLX  mechanisms  for  this  control.  Forms 
Kit  will  only  deal  with  layout  and  presentation  in  the  future. 

•  We  extended  documentation  of  the  generic  functions  in  the  Forms  Kit  into  a 
manual  using  the  Interleaf  System. 

At  this  point  the  Forms  Kit  system  had  been  factored  into  the  subset  necessary 
to  create  and  present  forms  and  the  subset  controlling  user  interactions,  so  that 
now  the  system  builders  can  use  the  underlying  CLX  mechanisms  for  this  control. 
Forms  Kit  only  deals  with  layout  and  presentation  now.  Documentation  of  our  Forms 
Kit  user  interface  facility  was  updated  to  reflect  this  factoring.  This  completed  the 
development  of  the  Forms  Kit  facilities. 

Some  later  additions  to  Forms  Kit  functionality  included  enhancing  the  interface 
package  to  allow  the  substructure  of  a  form  to  be  modified  after  it  has  been  created 
and  the  XI 1  Inter-client  Communication  Convention  Standards  (ICCS)  was  adopted 

*This  is  also  one  reason  we  implemented  Popart  using  Barrel,  rather  than  APS. 
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in  the  Forms  Kit  implementation,  allowing  more  effective  communication  between 
forms  and  XI 1  window  managers.  Functionality  can  now  react  more  gracefully  to 
mouse  clicks  and  other  gestures. 

4.7  Browser 

During  FY90  we  extended  the  APS  Browser  to  present  information  in  forms  tailored 
to  the  data  being  traversed.  This  mechanism  simply  allows  one  to  traverse  the  virtual 
database  from  the  terminal,  seeing  all  relations  with  other  objects  reachable  from  the 
“current”  object.  This  facility  is  particularly  important  for  HP  Bobcat  machine  usage 
because  of  the  general  inability  to  point  at  items  and  have  a  mouse  interface  that 
understands  how  to  copy  them  into  other  windows  (as  we  had  become  accu.stomed 
to  on  the  Symbolics  and  T1  Lisp  Machines).  Hence,  this  facility  —  coupled  with  the 
EMACS  interface  —  made  Bobcats  viable  alternatives  to  the  aging  Lisp  machines, 
by  providing  an  interface  with  a  ‘hyptertext  feel.’ 


4.8  Conversion/Porting 

During  FY89  APS,  POPART,  and  LUKE  (code  walker)  were  ported  to  Unix  worksta¬ 
tions  (running  Allegro  Common  Lisp),  and  our  browsing/viewing  mechanism  (Forms 
Kit)  was  ported  to  Xll/CLX.  Conversion  of  the  CLF  to  work  on  HP  Bobcat  ma¬ 
chines  continued.  Another  major  package  converted  this  fiscal  year  was  the  persistence 
mechanism,  ‘worlds’.  In  addition,  the  existing  CLF  source  code  was  restructured  into 
10  major  subsystems  with  known  dependency  links  (from  the  simple-minded  linear 
sequence  of  many  more  modules  that  used  to  constitute  its  structure). 

During  FY90  conversion  of  the  CLF  to  work  on  HP  Bobcat  machines  continued. 
The  large  ‘programming  service’  modules  were  converted.  Because  of  virtual  memory 
thrashing  problems,  conversion  of  the  ‘program  development’  modules  was  delayed, 
but  ultimately,  additional  memory  to  aided  the  situation,  and  the  development  service 
was  converted.  This  concluded  the  conversion  of  the  CLF,  but  the  system  remained 
unusable,  awaiting  conversion  of  the  editor  GNU  (EMACS)  on  the  HPs  to  act  as  a 
server.  This  editor  interface  was  the  final  missing  piece  of  functionality  preventing 
our  daily  use  of  CLF  on  the  HP  machines. 

During  FY90  we  also  converted  Popart  to  Barrel  and  ported  our  ‘AP5  Browser.’ 
Previously,  APS  had  been  converted  to  run  under  Allegro’s  version  of  Common  Lisp. 
Toward  the  end  of  the  fiscal  year  we  converted  APS  to  work  within  Lucid  Common 
Lisp  as  well.  Unfortunately,  AP5  stresses  every  Common  Lisp  implementation  it 
has  been  converted  to,  not  by  using  non-Common  Lisp  features,  but  by  extensive 
use  of  the  more  complex  features  (mostly  having  to  do  with  closures).  Hence,  every 
conversion  has  entailed  some  implementation  specific  “work-arounds”  to  stear  clear 


I 


I 


i 


I 


I 


i 


i 


14 


of  implementation  bugs.  This  one  only  entailed  implementing  non-Common  Lisp 
functionality. 

We  ported  APS  to  the  Lucid  Common  Lisp  implementation  on  the  HPs,  partly  to 
test  the  performance  of  that  platform.  The  performance  of  the  ported  CLF  was  in 
strumented  and  measured  under  different  memory  management  configurations  within 
Allegro  Common  Lisp. 

During  FY91  the  port  of  CLF  to  Lucid  was  completed  and  o-testing  of  the  CLF 
system  began  in  earnest  by  the  original  designers  of  the  kernel  facilities.  Later  the 
CLF  Allegro  port  was  given  a  thorough  beating  through  /9-testing  by  nondevelopers. 
The  normal  intensive  debugging  pains  were  incurred  for  a  period  of  several  weeks 

4-9  Protocols 

During  FY90  a  new  facility  was  developed  which  allows  remote  use  of  our  APS  virtual 
memory  data  base  by  a  client  machine.  All  relational  access  from  this  client  machine 
is  then  via  a  remote  procedure  call  facility.  In  effect,  this  allows  a  client  to  treat  APS 
as  a  traditional  relational  database.  The  technical  challenges  here  have  to  do  with 
maintaining  surrogate  relations  and  objects  to  track  the  state  of  the  other  machine’s 
view  of  the  server’s  state. 

We  also  completed  the  interface  design  between  the  CLF  system  and  GNU  (EM  ACS). 
The  design  calls  for  speeding  up  communication  by  replacing  the  use  of  files  for  in¬ 
terprocess  communication  with  uses  of  Unix  pipes  and  C  foreign  function  calls  for 
reading  and  writing.  Toward  the  end  of  the  fiscal  year,  CLF  was  converted  to  use 
a  new  interprocess  communication  protocol,  sockets,  instead  of  pipes.  Using  this 
protocol,  inter-machine  communication  is  possible,  as  well  as  the  local  editor/Lisp 
process  communication  that  it  replaced.  That  completed  the  conversion  to  GNU  and 
the  port  of  CLF  to  the  HP  platforms. 

During  FY91  a  prototype  local  area  network  “program  development  server”  was 
designed  and  demonstrated  wherein  program  objects  are  assigned  persistent  identifiers 
and  shared  between  several  workstations.  In  addition,  our  optimistic  sharing  support 
system  for  program  developments  was  propagated  into  the  design  of  this  server. 

The  conversion  of  AP.5  to  Lucid  was  finished.  We  were  pleasantly  surprised  that 
we  were  able  to  obtain  a  significant  performance  improvement  over  the  Allegro  imple 
mentation,  due  to  Lucid’s  facility  for  user-advice  to  control  the  number  and  sizes  of 
ephemeral  storage  areas  for  garbage  collection.  Additionally,  Lucid  promised  to  sup¬ 
port  our  eventual  RISC-based  HP  platform.  Hence,  we  chose  Lucid  as  our  Common 
Lisp  base  for  further  development  on  CLF  and  began  to  port  the  remainder  (bulk)  of 
CLF  to  Lucid. 

Finally,  The  CLF  was  converted  from  using  the  GNU  editor  to  the  Epoch  editor. 
Th  is  had  fairly  minor  effects:  allocating  a  single  1/0  buffer  per  process  became  po.ssi- 


ble,  and  “I/O  state  indicators”  can  be  used  to  indicate  a  process’  slate.  Most  inipor 
tant  is  that  Epoch  enabled  making  a  “Hypertext”  facility  availabi*’.  V\'e  f)r<jeraiiinu  <i 
the  ability  to  have  mouse  actions  available  for  (’LF  objects  printed  to  ordinary  text 
buffers. 

4.10  EGS 

During  FY89  we  made  progress  on  a  version  of  the  EGS  compiler  (our  specification 
language  subset  related  to  database  programming)  using  our  Popart  transformational 
mechanisms  called  ‘syntax-directed  experts.’  Although  development  of  this  language 
was  ultimately  dropped,  the  subset  was  later  explored  in  the  .XHIES  project  within 
our  division. 

4.11  Training 

A  training  manual  was  created  for  APS,  greatly  facilitating  its  transfer  to  Arthur 
Anderson.  The  creation  of  simplified  syntax  for  functional  use  of  relations  also  helped. 
A  manual  describing  our  persistence  mechanism,  ‘worlds’  wa.s  updated  thoroughly. 
The  manual  describing  our  Common  Lisp  code-walker,  ‘Luke,’  was  distributed. 

5  Important  Findings  and  Conclusions 

5.1  Ph.D.  Degrees  Awarded 

Surjatini  Widjojo  and  Ekl  Ipser  each  received  the  Ph.D.  degree  in  Computer  Science 
from  the  University  of  Southern  California.  David  Wile  was  the  committee  chairman 
on  both  committees.  Both  were  supported  by  the  CLF  project  during  their  tenure  as 
graduate  students. 

5.2  Collaborations 

During  F’Y88  significant  progress  wa.s  made  towards  de.signing  a  proposal  for  ‘Higher 
Order  Abstract  Syntax:’  a  concensus  building  activity  in  the  D.ARF’A  community. 
The  attempt  here  was  to  achieve  agreement  between  DARPA  contractors  on  a  .slati 
dard  interface  for  grammar-based  systems  so  that  components  from  different  sit(\s 
could  interoperate.  The  major  accomplishment  here  was  to  propose  a  non  intrusive 
version  of  the  higher  order  abstract  syntax -an  abstract  interface  to  it  is  provided  by 
the  designer  of  the  (simple)  abstract  .syntax.  This  way  the  repre.senf  ation  of  the  H().\S 
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does  not  have  to  dominate  systems,  but  can  rather  coexist  with  (possibly)  many  rep 
resentations  of  a  program.  Unfortunately,  no  implementation  t)f  tlu*  eoiKcpts  (e  g 
interoperating  with  other  universities)  occurred. 

In  order  to  understand  the  impact  of  an  open  architecture,  Unix-.style  program 
ming  environment  on  CLF,  and  in  order  to  gain  leverage  from  the  u.se  of  others' 
components,  we  began  talking  with  Tom  Cheatham,  .Mike  Karr,  and  Glen  Hollowav 
of  Software  Options  to  understand  how  their  E-L  language  and  environment  could 
interface  with  ours.  We  developed  an  agenda  of  repson.sibiIities  for  both  groups. 
Daring  FY90  we  converted  the  ‘worlds’  facility  (our  persistence  mechanism)  to  use 
their  ‘remote  lock’  facility,  rather  than  those  provided  by  the  file  system,  as  was 
our  practice.  In  addition  we  experimented  with  Software  Options’  “artifacts”  [tack 
age  with  an  eye  toward  integrating  its  coarse-grained  [)ersistence  management  with 
AP5s  fine-grained  object  management  in  the  virtual  memory  dalal)a.se. 

Also  during  FY90  we  discu.ssed  with  Lucid  Corp.  use  of  some  of  the  features  of 
their  Cadillac  system.  In  particular,  they  have  developed  a  protocol  for  talking  with 
editors  that  allows  communication  of  structural  modifications  to  buffers,  and  have 
converted  GNU  Emacs  to  use  this  protocol. 

During  FY90  we  intended  to  establish  a  communication  protocol  between  our 
Popart  System’s  transformational  semantics  package  and  UC  Berkeley’s  Pan  system 
for  editing  grammatically  structured  objects.  We  believe  that  both  systems  have 
been  designed  flexibly  enough  to  permit  the  appropriate  “impedence  matching”  to 
the  other’s  abstract  syntax  and  grammar  conventions.  Pan’s  grammars  are  more 
limited  than  those  accepted  by  Popart,  so  some  validity  checking  will  be  necessary  in 
the  long  run.  Unfortunately,  this  collaboration  was  not  really  consumated  in  the  end 

6  Significant  Hardware  Development 

None. 

7  Special  Comments 


None. 


8  Implications  for  Further  Research 


The  CLF  is  in  daily  use  in  LSI  s  Software  Sciences  Division;  for  several  r<'.s<'archcr< 
it  is  the  only  system  used  for  all  compulation  and  administration  needs.  It  forms  a 


solid  testbed  for  development  of  other  research  ideas^. 

Moreover,  having  ported  and  subsequently  exported  several  piect’s  of  th<'  svs 
tern  has  enabled  collaborations  both  within  the  division  and  institute,  and  beyond. 
The  ARIES  project  has  used  several  of  the  foundational  pieces  —  AP5,  !\)part. 
Popart/DB,  Kodewalker  —  to  prodtice  its  system  for  obtaining  and  reasoning  al>out 
program  requirements.  The  Popart  mechanisms  have  been  used  in  Knowledge  Base 
representation  systems  transformation  within  another  division. 

Furthermore,  collaborations  with  other  DARPA  contractors  has  b<?en  facilitated 
Subsequent  integration  of  some  of  the  Software  Options  artifacts  with  the  CLF  to 
provide  a  “process  programming”  base  have  been  especially  interesting. 

CLF  indeed  has  influenced  the  development  of  research  programming  environrn 
ments  —  e.g.  Marvel  on  Unix  by  Cail  Kaiser  —  and  the  development  of  industry 
products,  such  as  Cadillac  by  Lucid.  Virtually  every  modern  programming  cnviruii 
ment  has  adopted  some  of  the  concepts  for  an  integrated  programming  environment 
that  CLF  provides. 

Development  and  research  on  several  of  the  products  of  the  CLF  continues  on 
new  projects  now:  the  Popart  work  is  continued  on  the  Annotations  +  Metapro¬ 
grams  project  and  the  Relational  Abstraction  Compiler  Framework  continues  on  the 
Relational  Abstraction  project  in  our  division.  These  are  both  playing  key  roles  in 
the  emerging  technology  of  the  DARPA  sponsored  Domain  Specific  Software  Archi¬ 
tectures  program. 
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